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i.i iMzaaQuaiQM 

The purpose of this SON USERS GUIDE Is to set forth the 
procedures* techniques* and tools to be used by SDD {Sunnyvale 
Developnent DIvisionI personnel in developing Advanced Systems 
Release 2 software products. 

The prinary purpose of an SON is to assure that a project Milt 
neet requlrewents on schedule and within budget* as agreed to 
between management and the project. 

The SDH proposed in this document Is an evolutionary outgrowth 
of SOMs in use In Control Data since the early 1970s CPeterson 
1973, Hetzger 19731. 

This document* to the extent that it conflicts with Corporate 
Standard 1.01.106 "Software Development Model ••* constitutes a 
proposal to update the methodology of that Standard* insofar 
as that Standard Is applicable to the development of Systems 
Software. 

Mhi le this document Is concerned with current practices In 
SDD* It Is more concerned with how current practices can be 
shaped into a coherent and systematic SDM. 



1.2 MttALIS-Sflil 

SDM Is the family of Internal documents* technMues* and tools 
by which requirements become design and design becomes 
rieleasable code supported by published external documents. 

For the Sunnyvale Development Division* requirements* design* 
implementation, evaluation* and publication activities are 
recorded in the fol lowing family of documents: 

a. Requirements documents {controlled via DCS) 

- AO/R {CY180 Architecturial Requlrements/QbJectivesI 

- SIS {System Interface Specification! 

- GOS {General Design Specification) 
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- OR {Design Requirenents) 

- ERS lExternal Reference Specification! 

b. Design docuaients (control led via DCS! 

- 6ID (General Internal Design) 

c. Implementation documents (code controlled by code 
transmittal and PSR procedures^ documents via DCS) 

- PL (Program Library of documented source codel 

- PSR corrective code 

- Baseline documentation changes 

- IMS (Internal Maintenance Specification} 

d« Evaluation documents (PSTP controlled via DCS* others 
controlled by management procedures) 

- PSTP (Product Set Test Plan* for each code 
Release) 

- BER (Build Evaluation Report) 

- Approved Reviews (by Development and Evaluation) 
of Publications drafts of manuals. 

e. Publications (controlled by Publications procedures) 

- Reference Manuals 

- Operators Guides 

- Installation Handbook 

- Users Guides 

- "Instant" Reference booklets 

While the generation of these documents Is basically 
chronological due to logical dependencies inherent In the 
order given above* there is also an iterative process at work 
because as we learn more» we may have to revise previous 
documents. That is* requtrisments "drive" design and design 
"drives** code. Honeverf refinement of design can lead to 
revision of regulrements* and refinement of code can lead to 
rievision of design (and sometimes* revision of requirements). 



1 . 3 aAi£Liii£-fia£ua£int-2a£iSA-isi.£ Si-assiSi-itifi-&S£is 

Many of these documents are referred to as Baseline Documents* 
which are of two kinds: Interhal and external* subject to 
d i f f er ent sets of po I i c i es « 

Internal Baseline documents are: 

- AO/R 

- SIS 

- 6DS 
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- DR 

- ERS 

- 6ID 

- PSTP 

- IMS 

Exterhai Baseline documents are products of Publications: 

- Reference manuals 

- Operators guides 
Installation Handbook 

DAPs are usually generated during the Analysis and Design 
activities, each DAP addressed to a particular issue. The 
author of a DAP should identify In the DAP the sectlonCs) of 
baseline documentCsl tthich Mill be modified If the DAP Is 
approved. The content of an approved DAP should result In a 
BSL (baseline change) with change pages to an internal 
Cpossibly exterhall base! ine document. 

QSSs fQuotation Special SoftMare) and RSEs (Request Software 
Enhancement) which become features of standard software should 
be handled as are DAPs. A BSL with change pages for affected 
documents should be generated. 



1 .4 SQ£IMAa£-fi££ELa£fi£!lI-£aASES 

Initial development phases are product/project oriented for a 
given version or rieleases 

- Feasibi lity Phase 

- Definition Phase 

- Analysis Phase 

- Design Phase 

- Implementation Phase 
phases (plus the Featuris Test 



These 

oriented) are covered In the Project 



Plan, 
Plan. 



which Is product 



Concluding development phases are Product Set oriented toward 
a par ticular rei eases 

- Evaluation Phase 

- Pub I i cations Phase 

- Release-activity Phase 

In the past, maintenance has sometimes been considered a 
fortow-on phase. However, for Advanced Systems, AOSC Is 
directing that maintenance be handled in the same way that a 
new version would be: Go back to the Feasibility Phase and 
cycle again through all phases in an orderly manner. This 
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procedure should aid the preservation of structural integrity* 
Mhieh tends to erode over tliRe CBelady 1979> VanHorh 1980]. 



1 (Definition Phase 



a. Feasibi I Ity Phase 

- Deliverable documents are: 

- Project Plan* chapters 
Plan) and 7 (References) 

- GOS (first version) or other docuaentation 
describing the product In general terms for 
PLM and Marketing approval 

- The Feasibility phase begins Mhen Management 
initiates the preparation of a GDS or equivalent 

for submission to PLM and 



documentation 

Marketing* 

The Feasibility 



submission to 
concludes 



Phase concludes Mhen all 
deliverable documents are approved. 
GDS (at least a first version) Is preferable to an 
ad hoc document because a GDS Mill be produced 
later any May» based upon the ad hoc documents. 

vary among projects* and ad 

more suitable to particular 

GDS. 

Feasibility phase is to 

is a need in the CDC product 



HoMever* conditions 
hoc documents may be 
circumstances than a 
The purpose of the 
determine that there 



line for the proposed product* and to reach a 
general consensus upon the requirements for* and 
the architecture of* the proposed product. 



2 (Analysis Phase 



Mhen 
ei ther 



management 
del i verable 



b. Definition Phase 

Deliverable documents are: 

- Project Plan* chapter 
Plan) 

- GDS (final version) 

- The Definition phase begins 
initiates the preparation of 
document. 

- The definition phase concludes 
deliverable documents are approved. 

- The purpose of the Definition Phase is to define 
features* performance* and architecture of the 
product In sufficient detail to provide direction 
to the Analysis phase* during which all 
requirements Ml It be explicated. 



Mhen 
to 



all 



c. Analysis Phase 

- Deliverable documents ares 

- Project Plan* chapter 

- DR 
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- ERS 

- GID chapters 1* Z* 3> and 5 (Analysis Spec 
and Data Dictionary) 

- The Analysis Phase begins «hen management 
Initiates the preparation of one or wore of the 
Analysis Phase deliverable docunents* based upon 
evidence that the 60S Is sufficiently stabllzed to 
provide direction for the Analysis Phase. 

The Analysis Phase concludes Mhen all deliverable 
documents are approved. 

- The purpose of the Analysis phase is to nake 
explicit all feature requirementsy performance 
requirements* interface reguirementsy and to 
insure that the proposed product architecture 
supports ail knoiin requirements and ail envisioned 
future features and future requirements. 

d. Design Phase 

- Deliverable documents ares 

- Project Plan* chapter k (Implementation 
Phase PlanI and chapter 5 (Feature Test 
Plan) 

- SID chapter 2 (Design Spec and revised Data 
Dictionary) 

- Internal and external document BSLs required 
by Publications for manuals supporting 
releasabie code. 

- The Design phase begins when management initiates 
the preparation of either deliverable document. 

- The Design phase concludes Mhen all deliverable 
documents have been approved. 

- The purpose of the Design phase is to document 
explicitly the design of the product prior to 
coding. 

e. Implementation Phase 

- Deliverable documents arei 

- Sourse code PL 

- IMS 

- Revlexs of drafts of 
manuals 

- The Implementation phase begins 
initiates it. 

- The Implementation phase concludes 
deliverables are approved. 

- The purpose of the Implementation phase 
generate releasabie code that meets 
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docuiientation supporting the 
of their tasks. 



successful completion 



preparing 

Mith the 
chapter 5 



f. Evaluation Phase 

- Deliverable documents ares 

- Project Plan chapter 5» Feature Test Plan 

- PSTP (Product Set Test Pian» formerly System 
Test Plan in SDD) 

- System Test Plan (ARPO) 

- Test base programs and data 

- BER (Build Evaluation Report) 

- Testing activities are of two kinds 
test plans and tests* and testing code. 

- Feature Test planning begins 
preparation of the Project Plan 
(Feature Test Plan)* and continues with the 
generation of test code and data. 

- Product Set Test planning begins when 
management initiates the preparation of the 
PSTP (based upon all Feature Test Plans of 
all products of the set)* and continues with 
the generation of test code and data. 

- System Test planning begins when management 
initiates the preparation of the System Test 
Plan. 

- Testing of code begins when management 
initiates the testing of transmitted PL or 
PSR code for a release. 

Testing phase for a release concludes when 

management accepts the BER and approves code for 

release. 

The purpose of the Feature Test Phase Is to insure 

that the product code performs correctly according 

to functions specified in the riequirements 

documentation and the publications. 

- The purpose of Product Set Testing (SOD) is to 
insure that the versions of products In the 
to-be-released set function together correctly. 

- The purpose of the System Test Release activity is 
to Insure that all of the software of the Release 
operates together as a system and meets 
performance requirements. 



g. Publications Phase 

- Required deliverable documents are: 

- Manuals Test Plan 

- Reference Manuals (or Release 
packets) 
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<- Oiperator Guides 

- Installation Handbook 
Optional deliverable docuiiients ariet 

> Users Guides 

- Instant Reference booklets 

The Publications phase for a release begins when 

ffanagenent initiates preparation of <or revision 

of) a doeunenty foilOMing receipt from Development 

or Design of supporting documentation (e.g.» an 

ERS) to Marrent publications activity and 

providing resources are available. 

The Publications phase for a code release ends 

with submission of manual originals to Corporate 

Printing. 

The purpose of the Publications Release activity 

is to support released code itith external user 

manuals. 



h. Release^activlty Phase 
- Deliverables 

- PLs available 



SMD 



(SoftMare 



from 
Manufacturing Division) 

- External Publications manuals are available 
from LDS (Literature Distribution Service) 

- All Release Bulletins are available: 

SAS (SoftMare Aval I abi t i ty Bui I etin) 
SRB (System Release Bulletin) 
FAM ( Feature Abstract Memorandum) 
The Release Phase begins nhen management initiates 
steps to move the deliverables from Development* 
Evaluation* and Publications to the organizations 
that distribute the deliverables to customers. 
The Release Phase concludes when release materials 
are deliver ied to customers. 

The purpose of the Release Phase Is to insure that 
customers receive timely and coordinated service 
In connection with ne** releases. 
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SSHl 



2.1 EEAaiftXLIIl-EaAii 

The purpose of the Feasibility Phase is to explore the 
feasibility of a proposed product or product enhancement fron 
the Joint yienpoint of Harketing» PtH» and Development. 
••Feasibility" here neans "market feasibility" Cis there a 
profitable Barket for the proposed product?! rather than 
"engineering feasibility" (can the product be built to 
specifications?}* Mhlch Is exploried In the Definition Phase. 

For some prbduets» such as those for which there is agreement 
to meet an existing ANSI standard* the Feastblttty and 
Definition phases are relatively brief. For other products* 
such as Data Hanagement and Networks* there may be much effort 
required to define a product well enough to provide design 
direction for the preparation of Analysis Phase documents IDR* 
ERS* etc. I. This pre-An a lysis activity may not divide cleanly 
between Feasibi llty and Definition* but general iy Devel opment 
activity on a SDS sufficiently detai led to Min approval cannot 
begin until PLN and Marketing have established the market 
feasibility for the proposed product or proposed product 
enhancement. 

If the proposal is deemed feasible* then Development 
dellveriible documents of the phase arie: 

- Project Plan chapters 1 and 7. 

- 6DS (initial version! or other documentation describing 
the product in generial terms* for Marketing and PLM 
approvals. 



The intent 
Definition 



of the 
Phase. 



documents Is to provide direction to the 



The primary activity of the feasibility phase will probably be 
an exchange of memos among interested parties concerning 
features* archi tecturie* performance* and interfaces to other 



products which constitute a goal for 
be of permanent value* the outcome 
should be recorded In the 6DS or 
approved by PLH* Harketing* and AHPD 



a feasible product. To 
of this exchange of memos 
other documents to be 
and/or SDD. 
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2.2 Q££i!!lIIIQIi-EaAS£ 

DevetopMent deliverables of the definition Phase aret 

- Project Plan chapter 2 (Analysis Phase) 

- 60S If inal version) 

The purpose of the Definition Phase is to firn) up the 
decisions of the Feasibility Phase into a coherent set of 
requirnents (featuresy performance* archi tectyre* interfaces 
to other products) in a approved GDS. The object (or goal) is 
to provide a definition of the product and to provide design 
direction for the Analysis Phase. Prior to the beginning of 
the Definition phase* design diriection is not firn enough to 
result in an approved GOS» for PLM and Marketing are sti 1 1 
determining the narket feasibility of the proposed product. 
There nay also be budgetary considerations that restrict the 
resources avai table to prepare a GDS* and these considerations 
may also delay the transition from the Feasibility Phase to 
the Definition Phase. 



Reuqirements analysis Is one of the most difficult 
softnare developnent activities CBoehn 19791. 



of all 



Mhich seems to 



Re<iuire«ents analysis is an art» not a science* 

use the follOMing sort of dialectical processs 

1. The designer or design team* on the basis of the best 
and most complete inforiaation available* proposes to the 
custoffler(s) a design thought to meet all requirements in 
an optimum fashion. 

The customer says the design wi 1 1 not do because...* and 
another requirement which the designer was unaware of 
(and possibly the customer too unaware of before 
thinking about It) crawls out of the woodwork. 
The designer reworks the design* possibly 
but more likely by patching it* and goes 
1. 
4. The customer says that will not due because...* 

to step 2. 
••and the process iterates on and on. 

If the designer is lucky* the process terminates 

set of requirements (features* performance* 

Interfaces to other products). 



2. 



3. 



frot 
back 



scratch* 
to step 

and back 



In a coherent 
archi tecture* 



However* every requirement has a price and if the price is too 
high (low priority item conflicts with a high priority item* 
architectural structure is compromised* Implementation cost Is 
too much* etc.}* the "requirement** ceases to be a requirement* 
no matter how tenaciously held theretofore. 



H2 

I 

SSTTJ 

STTJ 

S 

SI 



SI 

SI 
SSTTJ 

STTJ 

STTJ 

STTJ 

STTJ 
SI 

SI 



1 
2 
3 

5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 



revision B 



USERS GUIDE 

SOFTMARE DEVELOPMENT METHODOLOGY ISDM» 



2-3 
09/23/81 



2.0 DEVELOPMENT PHASES 
2.3 ANALYSIS PHASE 



CODE 



12. 38, 58. 

LINE 



2.3 AtiALmi.£HAS£ 



2.3.1 INTRODUCTION 

The purpose of the Analysis Phase Is to finalize requirements 
and to cariry design far enough to insure there are no design 
problems In meeting the requirements spelled out In the DRy 
the ERS» and the Analysis Spec portion of the 6ID. 

Development deiiverahles are: 

- Project Plan chapter 3 

- DR 

- ERS 

- GID chapters I» 2* 3» and 



5 {Analysis Spec) 



If the softMare research I Iterature Is correct In claiming 
that a requirements bug caught after delivery of a product to 
a customer costs 270 times as much to fix as a coding bug and 
that a design bug costs 90 times as much to fix CMcCabe 1980]» 
then Control Data should be able to save many maintenance 
dollars by doing a better Job of generating and reviewing 
requlriements and design documents. 

SASD (Structured Analysis/Structured Design* CDeNarco 1978> 
Yourdon 197811 emphasizes the differience between data flow 
analysis Ca definition and requirements function) and 
structured design {a design function). 

Experience with SASD during development of Advanced Systems 
Release I products resulted in very few products doing both 
data flow and striicturie charts. Projects converting from 
CY170 had worked out their requirements during CY170 
development and had little need of data flow analysis. 
Structure charts* on the other hand* turned out to be useful 
for documenting design» though some projects found other 
techniques* such as state tables* of more value. 

For Release 2* there are severial techniques available* each 
with advantages and disadvantages relative to the differing 
needs of various projects. 

Beyond Release 2* it may be possible to use a specification 
language < such as BSL C Barber 19813) for analysis/design. 
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CODE 



12,38.58. 

LIME 



2.3.2 SA CSTRUCTUREO ANALYSIS! 

Structured Analysis fas defined and described by DeMarco) 
offeris useful techniques of decomposition* data 
triansforniatf onsf and data dictionary. 



Oeeoaposi tion is the technique 
prbgran In a one-page context 



of summarizing an entire 
r-i w»< «"• « <• « villi ft* If Ki 1.WIX.C*!. chart (to show data flow 
interfaces to other programs) and a one-page level DFO* and 
then decomposing each process in the level DFD into level 1 
DFDs» and so on down to as many levels as are necessary to 
define each bottom-level process in structuried English. 

Data transformation is technique of shoMing (Mith 
decomposition of datas files into records* records into 
segments* segments or tables into data elements) hoM output 
data is derived (directly or Indirectly) from intermediate 
files or tables and input data* and hOM intermediate files and 
tables are updated from input data. 



A data dictionary 
aggregations. 



defines all data elements and data 



Structured Analysis can be of great help to a project In 
defining the functions to be performed and insuring that 
interface requirements of users and other products are 
understood by the project and can be implemented by the 
project. 

SA Is supported by computer tools. The Data Dictionary CDCS 
ID«ARH3980} supports data descriptions and process 
descriptions. SASO Graphics CDCS I0-ARH39811 supports Data 
Flow diagrams. 



2.3.3 lA (IHFORHATION ANALYSIS) 

Information Analysis offeris the capability of defining data 
and the forms of data permissible during data 
transformations. It does not offer decomposition techniques* 
though lA can be used to define data at any level from the 
most abstract to the most detailed. Nor does lA offer the 
capabi iity to define data transformations (i.e.* the algori thm 
by which an output or file item is constructed from input or 
other file items). 

Information Analysts may be useful for projects whose main 
task Is to describe a data base (e.g.* the lADT project* the 
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SASD database to support Graphics 
Corporate Traffic project). 



and Data Dictionary* the 



lA is not supported by computer tools. lAF and ADAH are 
available for i«ple«entation» but are rather complex to use as 
Analysis tools* 



2.3.4 STATE TABLES 

State tables are a useful tool for complex programs where the 
reaction to a given input Is a function of the Internal state 
of the program. State tables have been used by Networks (to 
define protocol-driven programs) and Fortran/VS <to define 
symbol table processing). State tables can be very helpful in 
uncovering error cases* end cases* and infrequent cases that 
may be overlooked In the course of design* because the 
technique forces a look at all possible inputs for all 
possible states. 

While there Is no computer tool specifically supporting state 
tables* the Graphics structure chart capability can be used. 



2.3.5 DECISION TABLES 

Decision tables can be useful* for the same reasons that state 
tables can be. Essentially* a decision table is appropriate 
for a program that has only one state for a given set of 
inputs. For these cases* all data input/output cases can be 
def Ined. 

In the computer industry* there are COBOL-related decision 
table toots* but none seems Midely used in Control Data. 



2.3.6 STRUCTURED TESTING 

Structured Testing CHcCabe 19801 offers severial techniques for 
checking risquirement specifications: 

- Cause and Effect graphs Cpp 11-11* II-12)s For each 
cause mentioned In the ERS or Analysis Spec* there 
should be one or morie causes* for each effect therie 
should be one or more causes; and these should be 
coherent Cspeclfied by non-conf I IctIng and/or 
conditions). 

- Specification reviews (pp 11-18 thru 11-26) to insure 
sped f Ications are complete and coherent. 
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CODE 
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LINE 



2.3.7 DATA FLOW ANALYSIS VERSUS STRUCTURE CHART ANALYSIS 

It see«s to be a itatter of individual tenperanent that some 
prdgraaaers prefer data flow analysis while others prefer 
structure design. FeM programaers seen temperamentally 
equipped to view both as equally useful. This difference 
seems to have roots In a preferred position either that 
control flon is the logical consequence of data floM» or that 
data flow ought to be the logical consequence of control flow 
(i.e.y which has logical precedence: data flow or control 
flow? which is the boss» from a requirements point of 
view?}. 

The challenge of the Analysis Phase is to make sure that data 
flow requirements are understood prior to detailed design* 
otherwise the detailed design nay not be able to support the 
requirements of the program. Hence DeNarco's plea to set 
aside design until data flow has been analysed to the point 
where those specifying requirements have agreed that the 
proposed specifications meet the requirements. 



SH3 
I 



The crucial point is that the DR and ERS not 
modifications during the design phase» due 
management or the project having overlooked or 
riequiriements. 



be subject to 

to either 

mi sunderistood 



2.4 QESiai-EHAiE 

The purpose of the Design Phase is to complete design prior to 
Implementation (coding and unit testl. 

Development deliverables are: 

- Project Plan chapter 4 

- GIO (final version) 

" BSLs for internal and external baseline documents 

Evaluation del Iveriable: Project Plan chapter 5 

Publications del iver able: Manuals Test PI an 

SD (Structured Design! Is the principal methodology of design* 
as spelled out by Yburdon and Constant! ne. 

SO is supported by the SASO Graphics for SCTs (structure 
charts) and the SASD Data Dictionary for module descriptions. 
Nodule descriptions should be detailed enough so that there Is 
no ambiguity or open question encountered by the programmer 
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Mho translates the nodule description into code meeting CYBIL 
coding standards. This does not necessarily nean that the 
module descriptions are so detailed that each structured 
English statement Is the equivalent of one or a few lines of 
code. 

Structured Testing CMcCabe 19803 provides quidelines for 
reviewing design documents Ipp IV-20 thru IV-36). 



It is recommended that each project prepare a Project Notebook 
setting forth procedures that all project members 
to adhere to (e.g.» "NOS/VE Project 
Conventions**). 



are expected 
Procedures and 



2.5 lIi£Ua&MIAIIQ!!l.£tlAS£ 

The purpose of the Implementation phase is to generate code 
Mhich has been reviened and unit-tested f Development) » to 
generate test programs and data (Evaluat ion)» and to generate 
driafts of external manuals (Publications). 

Development deliveriables are: 

- Source Code PL 

- IMS 

Evaluations del iverables ares Test programs and data 

Publications deliverables are: Driafts of external manuals 

Coding and code revletis wM be done in accordance Mith 
SOD/ARPH coding staandards and procedures. 

The project should Insure that the procedures of the Project 
Notebook are adhered to (or revise the procedures so that they 
are adhered to). 



2.6 £]tAiy&iieii.eu4S£ 

Historically* the function of Software 
detect errors before a customer did» 
could correct bugs beforis the softitarie 
acceptance test or installed at a user's site CMetzger 19733. 



Evaluation has been to 

so Software Development 

was submitted to an 



Within the 
different. 



perspective of SDM* the function is somewhat 
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White soae persons look to proper 
code and a program that never tiad 
than one in which the hugs have 
others believe that the proper 



design to result In bugless 

any bugs is a better program 

been fixed CHIHs 19761* 

function of Evaluation is to 



pinpoint the origin of errors in the development process so as 
to debug the development process COeming 1981}* 

**During July 1981* Dr W Deming» the man whose ideas inspired 
the revolution In quality in Japanese industry conducted a 
four-day seminar for Control Data* He said: 

- 85% of product defects arise from the process 
produces the product* not from 
immplement the process. 

- Everyone is already doing his "best", 
defects* you have to find a better process. 

level of defects through test 



that 
the workers who 

If you want fewer 



If you reach your current 

and riework* you can find a process that 

— achieves the same level of defects 
without test and rework and 

— is more profitable than 
If you search for it* you can 
that 

--produces no defects 

— is more profitable than your currient 
The best use of your testing prbcess is to 

of your process lits inherent 



di rect ly* 



your current process, 
eventual ly find a process 



capability 

so that you can improve It." CHuntwork 



process, 
determine the 
defect level) 
1981* page 3.2.13 



If these remarks »re to be taken seriously* then for Release 2 
the various test plans should address how Evaluation will 
determine which part of the development prbcess is 
contributing to each error encounteried. In the literature of 
Software Engineering* these problems are discussed in CBoehm 
19751 and CBoehm 19763* among other places. 



Test plans are: 

- Project Plan chapter 5 

- PSTP IProduct Set Test 

- System Test Plan* AHPD 



Feature Test 
Plan)* SOD 



Sources of errors to be identified include: 

- Requirements activity 

- Design activity 

- Implementation activity 

- Publications activity 

- Evaluation activity 

Within each of these activities* a possible source of error 

revision B 
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wight bes 

- ofliission or oversight 
-> misunderstanding 

- poor documentation in a baseline document 

- poor docunentation or documentation in an 
document 

- "fell between the cracks" and some aspect 
deficient 



inappropriate 

SDM 



of 



is 



2.7 £UfiU£&XI0HS.£tiAS£ 

The Publications and Graphics Division has procedures for 
generating external baseline manuals and other manuals for the 
Planned code release. 



Development management 
together to establish 
meet their commitments for 



and Publications management work 
a schedule such that both groups can 



release. 



Najor Items of 

been mentioned 

- Internal 

schedule 



the interface betMeen Development and Pubs have 
in the phases aboves 

baseline documents must arrive in Pubs 
Inorder that Pubs prepare draft manuals 



on 
on 



schedule. 

- BSLs to external baseline documents must arrive in Pubs 
on schedule inorder that Pubs prepare draft 'manuals on 
schedule. 

- Pubs drafts of manuals must arrive In Development on 
schedule inorder that Development and Evaluation can get 
revieMed drafts back to Pubs in time for Pubs to make 
changes and stl I i meet the Release schedule. 

The key document in providing this schedule is the Pubs 
"Hanual Test Plan" prepared by Pubs during the Design Phaser 
with appropriate input from Development management. 



2.8 R£iEASErAaiMIIl-£tlAS£ 

Timely release of materials to customers entails much 
coordination among Developments Evaluation* Publications* 
Software Manufacturing* and Literature Distribution. 

The procedures for these activities are spelled out in the SDD 
Hinl-'procedures Handbook. 
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LINE 



3.0 a£iiLua£!iis 



SHI 



For each docunent» a brief description ts given« followed by a 
table of contents* Where appropriate* these skeletal tables 
of contents are based on CDC Standard l.Ol.lOO "Programming 
Project Hanageaent Standards'*. 

NOTE for any document containing a glossary! The ANSI 
Dictionary for Information Processing (ANSI X3/TR-1-77) 
defines technical terms not defined in the glossary of the 
document. 



3.1 ££Qi£CI.eLA{i 

Purposes To describe an activity In terms of hoM it is to be 
done* Mhen it Mill be done» ufhat the cost Mill be» 
what other prbiects are constrained* and what are 
constraining projects. 

The Project PIdn is a management document rather 
than a technical documenti. It should Include a 
minimum of technical detail about the product. 

The Project Plan is Included in this USERS SUIDE In 
order 



tos 

Standardize the format among 
Indicate the sequence in 
should be written* and 
chronological relationship 
chapters with other documents 



SDD projects 
which chapters 
Indicate the 
of Product PI an 



Contents 



The project 
document and 
(all may not 



plan is the contrblling project 
contains several parts. These Include 
be required for a given proJectM 



Chapter 1-— Definition Phase Plan 
Chapter 2— -Analysis Phase Plan 
Chapter 3— Design Phase Plan 
Chapter 4— Imp! ementatlon Phase Plan 
Chapter 5~Feature Test Plian 
Chapter 6— Post Mortem 
Chapter 7— References 
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Audience: 



Owner 



Author* 



Comments: 



Managers 
Planners 

Interfacing projects 
System test 
Oevelopiient project 
Quality Assurance 

SOD Management 



Project/Product Design Ichapters 



Oevelopnent 

l,2»3f7l 

Oevetopnent Project tChapter 4> 

Evaluation (Chapter 5> 

Developnent Project/Product 

(Chapter 61 



Design/ Evaluation 



All the planning docuaientsy as Mell as the post 
norteii» are included in this one plan. This makes 
the project plan more complete and meaningful. 
Since It is organized into chapters* the audience 



can go directly to the part that is of 
Most of the chapters above are based on 
that used to be stand-alone. Due to the 
these tiere stand-alone* a great deal of 
was noted. Collapsing the documents 
el i mi nates this problem. 



interest, 
a document 
fact that 
redundancy 

into one 



The Definition Plan describes objectives* 
deliverables* and schedules for the definition 
phase. The Analysis Plan does likewise for the 
Analysis phase. The Design Plan consists of 
objectives* milestones* and resources needed for 
the design activity. The Implementation Plan 
contains similar types of information* plus 
constraints* risks* unit testing plans or 
direction* and System Integrated Test CSIT) plans* 
if required. Descriptions of individual unit tests 
in the form of a matrix or a list will be produced 
by the project and/or the design team. These 
details need not be part of the IPP. The Feature 
Test Plan describes the activities to be performed 
by Evaluation to verify functional capabilities of 
a given product or feature* as well as activities 
requiried to verify the prbduct performance 
requirements as specified In the AQ/R and the OR. 
The Feature Test Plan also lists resource 
requirements* constraints* risks* and testing 
milestones. Plans for performing System Integrated 
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Test (SIT) cycles should also 
appropriate. SIT plans should 
the SIT plans outlined in Chapter 
plan. As with the IPPy specific 
and/or a test natrlx are provided 
project or by the design teats as a 
doeuaienti these details need not be 
FTP. The post morten is an infornal 



be included* if 

be in response to 

*t of the project 

test descriptions 

by the evaulatfon 

separiate Morking 

part of the 

docunent that 



describes Mhattient right Mfith the project* what 

went wrong with the project* and what could have 

been done to rectify bad situations in the 
project. 

Each chapter of the project plan can be considered 
either as a stand-alone document or as a part of 
the whole. Chapters are cospleted and distributed 
at different points in tine* and* in the case of 
the Feature Test Plan* are authoried by different 
people. Note that information Is not repeated in 
each of the chapters. For exanple* for each 
chapter that contains Milestones* the choice of 
Milestones should be only those needed by people 
other than the author and the author's Manager* for 
exaMple* interdependency Milestones. In chapters 
1* 2* and 3 only start and complete dates may be 
required. Intermediate milestones are not of 
general Interest and quickly become obsoleted by 
the PERT. 



Table of Contents? 

1.0 
1.1 



Oef Inl tion Plan 

Introduction 

Introduction to and sunmary of chapter 1. 

Relevant docuRents can be listed here or In 

chapter 7. Can contain a short technical 

description of the product* especially if 

the 6DS does not yet exist. 

1.2 Deliverables 

Project Plan chapter 2 (Analysis PlanI* GDS* 
and any other deliverables. 

1.3 Milestones 

Dates for start* DCS submittal* and approval 
of each deliverable document. 

1.4 Resources and Schedule 

Identify perison/months of effort for each 
calender month for each deliverable. 
Identify any other resources need for the 
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1.5 



2.0 
2.1 

2.2 



2.3 
2.4 



2.5 



3.0 
3.1 

3.2 
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for a given Product Set build 11 n SDD}. Only 
inforaiation that is not covered In other documents 
is noted here. One example of this type of 
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not be included* since that information 
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3*2 Testing Selection 

This subsection defines a rationale for 
selecting Mhlch of the conditions 
Identified in the section 3.1 are or are 
not to be tested* and identifies Mhich are 
to be tested and which are not to be 
tested* This section may refer to 
Individual feature test plans for details. 

3.3 Testing Procedures 

This subsection identifies the procedures 
that are to be used to execute tests» 
record results* report results* store test 
data and procedures* and document errors. 

4.0 Entrance and Exit Criteria 

There are three sets of criteria to be 
specified. These are: 1) mininusi criteria 
to be satisfied to enter and rienain In the 
system testing phase* 2) the miniffiun 
criteria to be satisfied to exit the system 
testing phase* and 3) the criteria for the 
software to become certified. This section 
describes the criteria tihich apply. 

5.0 Resource Requirements 

a) Personnel Regui rements. 
bf Hardnare Requirements. 

c) Software and Tools Requirements. 

d) Other Requirements. 
6.0 Schedules/Costs 

7.0 Responsibilities 

Each activity described in the plan must be 
assigned to specific organizations or 
individuals. 
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